Organizations that develop software systems typically receive and maintain collections of defect reports related to their software systems. Due to scarcity of resources, it is common that not all of the reported defects can be resolved before the software system is released. In such cases, it is beneficial to prioritize the collected defect reports so that the defects affecting the organization's success the most are addressed first. Commonly, defect reports are prioritized by attaching to each defect report attributes such as “priority,” “severity,” and other similar attributes. Such attributes are then assessed and assigned by the organization or by another party to disposition the defect report. Defects are then resolved in order based on their priority and severity.
However, this approach of prioritization may not be optimal for the organization's success for several reasons. First, the priority and severity ratings assigned to the defects are based on human judgment and may vary from person to person based on their skill and experience. Second, priority and severity ratings may sometimes be entered as higher or lower for idiosyncratic reasons. For instance, customers may overstate a severity in order to increase the visibility of issues affecting them, or engineers may understate the priority in order to reduce the workload of defects that need to be fixed before a release is shipped.
Due to the difficulty of assessing the priority of each defect, very severe defects are sometimes released with the product while less severe defects are fixed. When customers then experience severe defects they typically take action, such as forcing the software vendor to fix the defect immediately at a very high cost. In some cases, the customer may take legal action, depending on the legal terms of the relationship with the vendor. Typically, a loss of satisfaction and loyalty will result from encountering such severe defects, and this may lead to reduced repeat revenue for the vendor.
The situations where a customer encounters a severe defect, and where the vendor also suffers adverse consequences, may be referred to as “product defect escalations” or simply as “escalations.” Different organizations may have different operational criteria for distinguishing “escalations” from “non-escalations.” For example, defects which are brought to the awareness of the vendor's senior management may be considered “executive escalations,” or defects which are routed to a specialized expert support organization of the vendor may be considered “escalations,” or a combination of similar criteria may be used to define an “escalation.” Some defects may be escalations when they are first reported, while other defects may be reported as non-escalations (i.e., ordinary defects) and then later become escalated.
A system to predict which ordinary defects will later become escalated may be beneficial to an organization. Such a system would allow these defects to be corrected proactivelty and at lower cost, as opposed to correcting them at a higher cost after an escalation occurs. The term “costs” here may refer to various types of costs such as labor cots, loss of customer satisfaction, loyalty, repeat revenue, and other similar types of costs and adverse consequences.